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PREFACE 


"Towards Management Information" is one of a series of 
documents produced by the National Work Group on Justice 
facormation and Statistics (NWG) to improve national justice 
MmeOcmacion and statistics. Le bringss under ~one cover a 
number of initiatives connected with NWG Project 5. At the 
January, 1979 meeting of the Federal Provincial Advisory 
Committee on Justice Information and Statistics (FPAC), the 
NWG was authorized to provide, on request, assistance to any 
jurisdictions in helping to define their information 
requirements and to develop a methodology to support this 
activity. This document seeks to outline the framework needed 
in developing an information system and the steps identified 
Cann Serve Tas oa checklist for ‘that ‘process. Auxiliary 
considerations, such as documentation and security are 
mentioned, though not discussed exhaustively. 


the. NWG, |) principaliiy, G. #Genvais;s J. 4Johnston,. GC. 
Gainer and A. Hourdebaigt, developed a systematic hierarchical 
methodology which is described in Appendix A. AchPOrter my En 
anticipation of requests for NWG assistance, compiled a 
framework or list of steps in which this methodology could 
operate. Section 3.0, outlines some considerations to support 
the steps of Section 2.0 although it does not purport to be an 
exhaustive commentary. A. Hourdebaigt provided the 
documentation standards described in Appendix B to Quebec who 
are documenting their justice information system with a view 
of it being a model for other provinces. 


The methodology and general approach was used during 
the Summer of 1979 with the Yukon Territorial Government who 
had requested NWG assistance in defining their justice 
requirements. "Towards Management Information" was_ the 
subject of a paper presented by A. Porter to the U.S./Canadian 
Workshop on Corrections Information Systems in September 1979 
aeavectoria, B.C. Ge sGervais also: utilized Section 3.4 on 
Technology Transfer in a paper to the Federal/Provincial Data 
Dissemination Committee on January 23, 1980 for their annual 
meeting. 


The NWG hopes that this document will prove useful to 
agencies in the justice field who are developing or assessing 
their information systems. 


The NWG welcome any comments concerning this document 
and have provided a sheet for that purpose. Any “Errors “Or 
omissions are the responsibility of the author. 
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TOWARDS MANAGEMENT INFORMATION 


Introduction 


Management is becoming increasingly aware of the need for 


quantitiative information in order to manage. To, obtarny, 
Organize and control such information requires some sort of 
Management Information System (MIS). The Police Management 


Information Systems Study of the Federal Solicitor General(l) 
define a MIS as "the process whereby data is collected, stored 
and retrieved to provide specific information for decision 
making". 


This applies to decision-making at all levels of operations 
and management. A MIS may require computers, if warranted by 
cost, timeliness and volume, but this is not necessarily so. 
Technologies, including computers, are merely the means by 
which an MIS may operate. 


Information in an organization is a resource which may be 
e0stiy "to Egenerateng SEOLC ancOPyin cotransmait, ,<retmieve and 
disseminate but it has an impact far in excess of its cost. 
For an-organi zations” inftormataionjadikey electricity,; ssa form 
of energy"(2). It is both necessary and important but there 
is a need to manage and control it. The MIS is merely the 


tool by which this management and control of information can 
be achieved. 


The purpose of this technical report is to indicate a means by 
which an MIS can be attained either from a situation where 
there is no existing system or where present system(s) do not 
appear to meet the current needs. The approach advocated here 
is predicated on the following: 


i) Satisfaction of local operational needs by the MIS; 


ii) High involvement and control by operational staff, 
managers and policy analysts in the specification and 
development of the MIS; 


TiijeMarntenance of one data base fromswhich all users can 
derive their data. Generally this means obtaining 
statistical information for policy planning, research, 
and national reporting as a by-product of an 
administrative system; 


iv) Utilizing transfer of existing technology wherever 
possible; and, 


v) Planning which involves all relevant parties, with the 
production of a master plan to guide overall 
development. 


Zonk 


Steps in Developing an MIS 


Certain steps must be taken in an orderly manner to develop a 
MIS. The ones described here largely are taken from the 
OBSCIS Implementation Plan(5). For convenience these are 
grouped into phases: 


- ~RECOGnLELON; 

e  elnidterationy 

- Review and Evaluation, 

- Overall MIS Design, 

- Detailed Design for Each Module of the Master Plan, 
- Achieving Operational Status. 


NOB WH EF 


Each of these phases has provision for management review at 
teswconclusitoen! and? bys implication; anv opportunity to*haltathe 
developmental process if it appears faulty. These phases are 
further oil Tusitrated: in Figure). ov Enphasts8is®ons planning <and 
defining requirements before proceeding on a large _ scale 
development. It is far easier and cheaper to alter directions 
before the system is developed rather than afterwards when 
there will have been large scale expending of resources. Once 
a “system ,is°°in )-placeone: scan be@?*locked in" Ytow@eertrain 
concepts, data collection procedures or equipment and it may 
be difficult to extricate oneself from these. 


Recognition 


Senior management must recognize the need for a MIS and this 
must be impressed on all levels of authority. Tt will foe 
perceived at this stage that current information systems are 
not satisfying expected requirements althougim*this Slack of 
Satisfaction may not be precisely identified. However, 
Management will feel compelled to initiate some action which 
may ultimately lead to a new MIS. Aetioni"arrswng?st rom. ‘thas 
recognition will vesult ins 


- a broad statement of the perceived problem; 

- general terms of reference to be given to a project team or 
task force. This would include goals, objectives and scope; 

- commitment of resources to initiate a MIS development with 
some indication of the eventual total commitment of 
EEGSOULCES CTO Chis project. 


Initiation 


2.2.1 Organize the Project Team 


2.2.1.1 Identify a Senior Management Review Committee 
(Optional). This may be needed if the members of the 
Steering Committee (Sections 2.2.1.2) se aren enOu mmateG 
senior management. This group will be the ultimate 
authority and make the commitment of resources. 
Matters not resolved by the Steering Committee will be 
referred to this body. 


FIGURE 1 


STEPS IN ADVANCING A MIS 


1.0 RECOGNITION 


INITIATION 


Organize Team 
- Define Scope 
- Establish Goals 
Review Scope and Goals 
Plan for Next Phase 
- Establish Control 
Review Plans 
Obtain Management Commitment 
for the next Phase 


REVIEW AND EVALUATION 


Analyse the Environment 

- Analyse Current Systems 

- Define Requirements 

- Define Problems in MIS 

Review 

Define Purpose, Objectives 
of a MIS 

- Analyse Strategies 

- Prepare Preliminary 
Definition of the MIS 

- Prepare Master Plan 

Review Master Plan 


Obtain Management 
Commitment to the Master 
Plan 


4.0 OVERALL MIS DESIGN 


Initiate Systems Development 
Refine Defined MIS 
Convert Defined MIS to a 
Conceptual Design 

Third Party Review of 
Conceptual Design 


FIGURE 1 


STEPS IN ADVANCING A MIS (CONT. ) 


—— — eee i i el 


Refine Master Plan 
Review Final Conceptual 


DETAILED DESIGN OF EACH MODULE 


- Complete Detailed MIS Specifications 
— Review Module by Third Party 

- Establish Final Resource Requirements 
- Management Review 


ACHTEVING OPERATIONAL STATUS 


Develop Module 
- Train Modules 

- Plan, Conduct System Acceptance 
Evaluate after Implementation 


Dio, 2ce Lied Constitute a Steering Committee. This 
Steering Committee should have representation from 
agencies concerned with the MIS. The members should be 
Management that is senior to project team members. 
This committee will review and monitor work of the 
project team and try to resolve problems referred to it 
by the project team. 


2.2.1.3 Select Project Manager. This individual will 


be given terms of reference including his 
responsibilities and authority. Ideally he should 
represent the final user of the MIS rather than be a 
"technical expert" since ultimately .the MIS must 


"belong" to the user. 


Y Sg Bek OAL Select Project Team. Identify members with 
appropriate skills for the team and select the core of 
the team. These core members must be committed to work 
during the Initiation Phase. Emphasis should be on the 
skills rather than status of the members and on the 
commitment expected. It is best to select members from 
areas to be directly affected by the MIS. 


2.2.1.5 Furnish Team with Initial Terms of Reference. 
These will include goals and objectives for the team, 
expected authorities and responsibilities, constraints, 
Management's perception of the problem She 
Informal Von Ge Ss CODe,. PETOriltres ja sand —~any. background 
material. The team will require this to refine their 
Own perceptions and generate workable definitions of 
scope, goals and objectives for the project. 


Define Scope 


Page dep 9 Bead Review Constraints. These could involve 
resources, accessibility to information and the legal 
Situation. This should also consider other concurrent 
developments and anticipated changes. 


IM aI ABS 4 Refine and Detail the Scope of the Project. 
The. sproject “team witl”* “use the ~inreral “terms” “ot 
reference to prepare a precise and workable statement 
of the project scope for review by the _. Steering 
Committee. For example the MIS may be defined by 
Management to concern the Canadian Criminal Justice 
System but its precise definition and bounds may be 
detailed by the team. The scope will be tempered by 
what the team perceives iS realistic in view of 
constraints, terms of reference and the capacities of 
the team. 


Establish Goals for the Management Information System 


(MIS ) 


The team interprets and details the goals in the 
Initial Terms of Reference to prepare a workable set of 
goals and objectives suitable for presentation to the 
Steering Committee. These should include: 


- type of information expected from the MIS, 

- timeliness requirements, 

- possible methods of supplying information, 

- key operational functions and perceived problem 
areas, 

- possible links with other MIS's. 


These goals should be measurable and allow one to 
determine when the MIS has been achieved. 


Review Scope and Goals by Management 


PRS AT WA Review Scope. Management ensures its 
intentions are’ included in the scope and extraneous 
functions are not included. 


2.2.4.2 Mutually Agree on Scope by Team _= and 
Management. The Steering Committee and the Project 
Team will arrive at an agreed-upon version of the scope 
of the project and commit themselves to it. 


.2.2.4.3 Review Project Goals. Management ensures that 


its intentions are defined, understood and included in 
the goals and objectives as produced by the team. All 
extraneous goals should be deleted and all constraints 
should have been considered. All goals should be 
challenged for reasonableness and achievability. 


2.2.4.4 Mutually Agree on Goals by Team _= and 
Management. The Steering Committee and Project Team 
will arrive at a agreed-upon version of the goals for 
the project and commit themselves to these. 


2220409 Set Priorities. Management will set 
priorities on the goals of the project. 


Develop a Plan for the Review and Evaluation 


2.2.5.1 Determine Activities Required to do the Review 
and Evaluation. These include identifying personnel 
and obtaining documentation which may help describe the 
current “status, environment (relevant legislation, 
policies, directives), current information, needs. The 
methodology and approach to performing a review and 
evaluation will be selected along with instruments to 
perform at. Each activity will be broken down into 
small identifiable tasks for purposes of scheduling, 
identifying resources and assigning responsibility. 


2S25 2 Schedule Tasks. This scheduling involves 
estimating both the elapsed time and resources required 
for each task as well as any logical sequencing of 
tasks. The schedule will be subject to the 
availability of personnel to be interviewed and other 
external factors as well as uncertainty in the 
estimates themselves. Thus the schedule should have 
sone =contingency =*built into’ it > sot “‘that-* the “final 
product of the review and evaluation exercise, a master 
plan for the MIS, can be produced on schedule and 
within budget. Each task should show’ the person 
responsible for its completion. 


PAP A ee BAS | Estimate Costs. The cost of performing the 
review and. evaluation can be developed from estimates 


for each step. These costs should include internal 
personnel with overhead as well as services, material 
and travel. In approving the plan for the review and 


evaluation, management will be committing itself to 
expending these resources. 


Establish Methods of Project Control and Management 


Review 


Dre Dre Ole a Refine Reporting Structure. Tris’ wll utilize 
the terms of reference to prepare a detailed and more 
precise description of reporting structure to be expected 
during both the review and evaluation phases and include a 
schedule of review meetings. 


2.2.6.2 Identify Progress Reports. The team will propose 
the types of progress reports to be sent to management. 
These will include regular reports, milestone reports and 
other special reports as well as the timing and content 
of such reports. 


Review Plans by Management 


Dse2yey! oth Check on Reasonableness of Plan. The Steering 
Committee will review the plan to check if: 


- identified tasks are necessary and sufficient, 

- cost and time estimates are reasonable, 

- resources can be available when needed, 

- outside personnel to be interviewed well be available 
when scheduled. 


2.2.7.2 Determine if Plan Fulfills Objectives of Review 
and Evaluation Phase. Management will satisfy itself that 
the planned work is going to achieve the agreed-upon 
goals and that the investigations cover the scope of the 
study. 


PAS 


Review 


PAR Ne 


22a tes Mutually Agree Upon Reporting Structure and 
Methods. The Steering Committee will review the proposed 
reporting structure and schedule of reporting as well as 
its contents and amend them to suit their needs. This 
reporting will be used during the Review and Evaluation 
Phase and may be extended to encompass further phases and 
thus becomes part of the plan. 


Obtain Senior Management Acceptance and Commitment for 


the Review and Evaluation. 


2 Lee Steering Committee Accepts Plan and Commits 
Resources. The Steering Committee, based on its review, 
will accept the plan for the Review and Evaluation or 
rejeet: wet. Li; accepted, sity.wi ll. ensure, thaty resources 
will be available to carry out this phase. 


2.2.8.2 Senior Management Review Committee Approves Plan 
(Optional). If there is a Senior Management Committee it 
will approve or disapprove -the-eplanwa, ifirapproved, 1t will 
commit resources and ensure organizational commitment to 
this phase. This should guarantee cooperation in the 
interviewing and obtaining of information which must 
necessarily occur during the review and evaluation. Tf 
members of the Steering Committee are senior management 
they will have done this. 


and Evaluation 


Analyse the Environment for the MIS. 


2.3.1.1 Analyse the Organization. The team will obtain 
information on the organizations which will be involved 
with the MIS. This may be formal organization charts 
supplemented with statements concerning the goals and 
objectives of the organizations, legal mandate, (where 
applicable), responsibilities, authorities, job 
descrintions, and present and future resources. Such 
background material can help identify the organization's 
services, responsibility/authority balance, stresses, 
public accountability and responsiveness. The decisions, 
tasks!, “activ bites). finctions= andmMauthority structure of 
an organization help define its information needs. 


pra LS Fe Identify Environmental Constraints. These 
contraints relate to external factors such as legislation, 
geography, population to be served, economic conditions, 
experience, practices and traditions. Such constraints 
May have a major bearing on what can be possible in a 
Master “plan for ‘an IMIS* For example strong pressure 
groups and a general distrust of government could prevent 
integrating health and justice information on 
individuals. Budget limitations for the development and 
operation of an MIS must be understood as well as the 
Capacities of personnel and the availability of other 


Pe Ti 


resources. It would be folly to propose a high technology 
MIS to an Organization with no computing background and no 
budget? tol get, into. 


The) mdenttfication-of environmental. constraints will aid 
in identifying and defining problems affecting the speed, 
thoroughness, efficiency and quality of administrative 
processes. This background is necessary to determine the 
Oasic Or core problems concerning information. 


Analyse Current Information Systems (Present Status) 


2 td Dol: Define Current Manual and Automated Systems. 
This involves collecting all documentation and 
interviewing where possible those who designed and those 
whor'now /Operate therrsy.stem. SLE jisimcritical. to», identify 
Operational procedures which have evolved beyond the 
existing documentation. Individuals' perceptions of the 
systems may be as valuable as actual "facts" determined 
from documentation, reports, etc. Determining how 
individuals interact with the various operations will 
provide insight into the human processes affecting systems 
bunct.rons. It will be important to establish a glossary 
of terms so there is common understanding. The definition 
of the systems and procedures will identify: 


- Files and data elements, 

- reports produced (contents, frequency and distribution 
and the use made of these reports), 

- source and mode of input data (reliability, content, 
frequency, volume), 

- controls to ensure integrity of the data, including all 
editing and follow-up procedures, 

- clerical work to support the systen, 

- access to files, 

- security, privacy,.and confidentiality of data, 

- organization responsible, 

- other organizations which interface with the system 
and data linkages. 


A flow chart illustrating the decision-making processes 
will aid in portraying present systems. The output from 
these current systems gives the current supply. of 
information. 


Deis ais 2 Identify Resources Supporting Existing Systems. 
These resources include manpower (numbers, levels of 
skills), equipment (Electronic Data Processing and manual) 
and their respective costs. With respect to equipment, 
the excess capacity should be identified. This excess 
capacity of equipment and the staff can determine limits 
to growth of the present systems and it can also be 
assessed with respect to use with any proposed MIS. 


10 


Be sarees Determine Future Plans. This involves 
investigating plans for new systems or modifications to 
present ones and will include changes in manpower 
resources and equipment facilities. The main purpose of 
this step is to ensure that the analysis of the present 
status is not obsolete before it is done and to understand 
how these planned changes could impact on a new MIS. 


2.3.2.4 Assemble Documentation and Review. This may 
merely be a formalizing of existing documentation but it 
should be reviewed with present systems personnel as 
future decisions may be based on this documentation. Et 
may be necessary to revise some documentation in light of 
information obtained «im Section 2.3.2.1. 


2.3.2.5 Consolidate User Statements about the System. In 
the process of reviewing existing systems and procedures, 
the users may expose various problems with the system and 
some suggestions for improvement. This analysis of the 
current system may afford the user an opportunity of 
making his views known. 


Define Requirements 


23 5a tk Determine the Organization's Demand for 
Information. Bhiss Gexercise will define whoredngmenc 
organization needs what kind of information for what 
purpose” sand. how —sftrequentiy. The information needed 
will be described in terms of reports and data elements 
withtheir precision, accuracy, frequency, timeliness, 
‘and importance. An instrument for systematically 
defining the organization's demand has been developed by 
the National Work “Groupivon, /Justice ciInformations and 
Statistics \(NWG)Y" and as*odescribed* “ins Append rx, A: A 
complete determination of the demand for information will 
include the needs of outside users. 


Diese Sete Analyse the Demand. This exercise will 
utilize information gathered in the previous step to 
identify and eliminate duplications in definitions and 
seek common definitions. Thiss‘*step- may’ not “bei siwihhy 
realized but should have been well-initiated with its 
eventual completion forming part of the Master Plan. 


Define Problems in the MIS. 


Zest ak Compare Requirements with Existing Information. 
All requirements for information are most likely not being 
met by current systems. These shortcomings of the present 
systems would most likely be in the areas of accessibility 
of data, completeness of data, and reporting 
capabilities. Other problems may be that the resources 
required for current systems do not seem justified in 
terms of) information wroduced- This comparison should 
result in a concise report to management showing the needs 
which are not being met by current information systems. 


Diet soi’ ote Analyse Organizational Problems. Some 
difficulties in satisfying information needs may highlight 
Organizational problems. These include policies and 
procedures which impact on data processing, controls, 
auditing features and organizational aspects of data 
processing. Such problems would be addressed by 
Management. 


Review Requirements by Management 


2 Seek Check that Requirements are Complete _ and 
Correct. From the perspective of the Steering Committee 
the totality of the requirements can be assessed for 
completeness and correctness with respect ro 
Organizational needs. it feat onrdse@ani soppontunity. to 
evaluate the information being produced in light of what 
is desirable. 


2.3.5.2 Set Priorities. The Steering Committee will set 
the priorities on information requirements. These will 
govern how the master plan is constructed and represent 
management input to the process. 


Define Purpose and Objectives of the MIS 


2 Sie orl Determine the Information Problem. The Project 
Team will analyse the information presently produced with 
respect to the scope and goals defined during the 
InwtVvatron ys Phase and  owith respect to requirements 
identified. Such an analysis will show which information 
needs are not being satisfied by current systems and 
procedures and this comprises the information problem. The 
costs of operating present systems should also _ be 
considered as these may be too high and suggest the need 
for more economical means of processing. 


The definition of the problem will also focus on: 


—yaccessibalatymol data 

= completeness of data processing and reporting 
procedures, 

- statistical reporting capabilities, 

- policies and procedures, 

= control and auditing, 

- organization. 


2.3.6.2 Set Objectives for a MIS. The Project Team will 
formulate arsset. of, objectives. [org-an +MIS™ based -one lthe 
requirements, constraints, general objectives and scope. 
Such a statement will form the basis of the definition of 
a MIS. 


a 


2 


Analyze Strategies to Meet Objectives 


oe ae oh Review Other MIS'‘s. The Project Team will 
review other systems and approaches which appear to 
responds to! similar, infiormation problems sas 3sete torch or 
this: MLSS (SeéeuSectien! 2es76.")i. This review could include 
literature of other systems, visits to examine systems 
under operation, documentation on packages, and reports 
of. MIS™s “In” others organizations. This review will 
identify discernable overall alternative strategies and, 
for each, the costs of development and operation will be 
estimated and its advantages and disadvantages listed. 


Iva) eZ Select Favoured Strategies. The Project Team 
will select the more favoured alternative strategies that 
are also feasible and prepare them for a decision by the 
Steering Committee. There should be at least two 
alternatives but not a plethora although background 
material indicating the full range of alternatives should 
be presented in such a way that the Steering Committee 


can be aware of them. The presentation will indicate 
costs, advantages and disadvantages and suggest tangible 
benefits which one or the other can achieve. These 


strategies refer to overall approaches to developing a MIS 
(e.g. manual, batch computer, on-line system) rather than 
details which will be decided later. 


Zee (eS Choose a Strategy. The Steering Committee will 
choose one of the alternatives presented. This committee 
will satisfy itself that the alternative chosen will meet 
they “oObyectives' of «thee MES ewithin Sstthesetconstrarmnuce 
Perhaps no alternative will appear satisfactory so it may 
be necessary to search for other strategies, change the 
constraints e.g. seek more resources, or abandon the 
exercise. 


Prepare Preliminary Definition of the MIS 


2.3.8.1 Identify Data Elements. The project team will 
prepare a list of data elements to be carried in the MIS. 
This will include the common definition and a 
specification of coding. The data elements may be needed 
for their own intrinsic -value;7- record “1dentreicativon, “or 
linkage to other MIS's. 


Ze deGee Define Required Outputs and Inputs. The outputs 
represent information needed by users and could be 
reports, enguiries, notices and expected future 
requirements. Outputs should be defined in terms of 
volume, content, frequency, distripucLon and media. 
Inputs represent the information being put into the MIS. 
They*=should™ be defined "in “terms: of content;> frequency) 
quality, method of collection and source. 


2.3.8.3 Define Functions to be Performed by MIS. This 
will indicate what is to be done to the information in 
thewareas’ Of Mupdating,™ editing," security and aqintegrity, 
and retrieval of the data. 


2.3.8.4 Compile Preliminary Definition of the MIS. 
tise lies bee idonel bya" ithe a Projectl.Teamesitfirom= the 
foregoing and presented to the Steering Committee for 
approval. 


Prepare Master Plan to Achieve the MIS 


A comprehensive master plan _ for intormataen brings 
together the supply of information (current information 
and its availability) and the demand (requirements by 


mee OEganizatvon forshintormat ron). ite represents a 
"front-end investment" in planning for the development 
CEM agMtLsS + Having such a "front-end" will address the 


requirements and not simply make the current supplying of 
information more efficient. 


The master plan will serve as a framework for future 
development of a MIS. It wibl “be the-culmination of the 
previous activities. 


239 io) Assemble Background Documentation. The Master 
Plan will be a comprehensive package indicating not only 
the overall plan but background information for 
completeness. The package will include: 


a) “Scope ,and,Goals:.forn -the MIS) (Section 2.2.4), 

b) Methods of Project Control and Management Review 
(SEGELONT2 256) , 

e)r «Set of Requirements (Section) 2.353), 

dad) Purpose and Objectives of the MIS (Section 2.3.6), 

e) Preliminary Detinition- of the MLS (Section? 2.3.8). 


2236962 Define Overall Strategy for Development. MThis 
will outline the overall strategy in the master plan and 
include some discussion of alternatives considered 
(SEG titon th. 2) hohe (Oe If computer hardware is part of the 
strategy a broad definition of the hardware required will 
be included. Out of this can result the overall system 
design to identify major components. 


2.3.9.3 Develop a Schedule. Major steps and milestones 


in the development strategy will be identified. These 
willl ibe ¥y scheduled’ ‘takinory due, iognizance. (of -cspeciric 
development DEVOrLt les. A staffing plan and an 


expenditure schedule will be necessary Supporting 
information. 
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2.5.9 34 Estimate Costs. The developmental and 
operational costs will be estimated. These will include 
personnel, hardware (if relevant) and services. 


2.3.10 Review Master Plan by Management 


2.3.10.1 Confirm Master Plan is within Scope and Goals. 
The Steering Committee will ensure that the Master Plan, 
as presented, is within the scope and answers to the 
purpose and?) goals set for «the MIs. 


2.3.10.2 Approve Master Plan. The Steering Committee 
williceither ‘approve the:tplan, simoditysaitesor Arejecre a1. 
entirely. At this stage it is relatively inexpensive to 
change basic approaches >but sonce’sthe splantem yaccepted 
and commitments are made it can be very expensive to 
change fundamentals. The Steering Committee may also 
have to procure exe resoumces to eancy, out 
implementation of the Master Plan. 


2.3.11 Obtain Senior Management Acceptance of and Commitment 


to the Master Plan. 


Senior Management will approve and accept the Master 
Plan as the blueprint for the development of an 
information system throughout the organization and 
ensure sufficient resources are committed to it. This 
Master Plan can also lead to great changes within the 
organization so that its successful implementation will 


only be possible if the entire organization understands 


senior management's support and commitment. 


Overall MIS Design 


2.4.1 


Initiate the Systems Development 


2046151. Develop an Organization. Thess involves 
forming and staffing an organization for developing the 
system and then one for operating it. The Project Team 
for development may be quite different from the one 
used during the Review and Evaluation Phase. For the 
group(s) charged with developing and operating the 
system it will be necessary to: 


- define various jobs and develop job descriptions, 
- develop policies, 

- define training, 

staff defined positions. 


PART: el Bw Develop Standards. Standards will be required 
during the development of the system which will include 
design “conventions, *controls,;,*%and’ formathy of Efrequiired 
documentation. It may be possible to adapt existing 
Standards but these must be explicitly stated, known and 
adhered to by the development team. 


Refine the Defined MIS 


2.4.2.1. Finalize Detailed Requirements of the MIS. The 
project team can return to the users with a mandate from 
Senior Management to design a MIS under an accepted Master 
Plan. At this point the composition of the team may be 
changed from one equipped to study systems and produce the 
Master Plan to one which will be charged with carrying out 
that Master Plan by developing systems. The team can then 
review requirements and obtain more detail regarding 
inputs, Outputs, functions required and constraints. This 
Will enable the project team to produce a more detailed 
dSEasn iti one otct hemM hss ehoughintitis.(defindtions wills still 
be expressed at a non-technical level. It will represent 
a functional description of the MIS stating what the MIS 
will do and be. 


2.4.2.2. Approve Finalized Definition of the MIS. The 
Steering Committee will approve this finalized 
description. Thisscdescrerprtion swwllepbeyjthe- basis for 
systems specifications. 


Convert the Defined MIS into a Conceptual Design 


254 o 301 Produce an Overall System Design. The Project 
Team will cause an overall systems design to be 
produced either in-house or under contract. SUCGion ad 
design will consider modularity, mode of processing 
(manta, on-line or..batch  computing).,,..overall file 
Structure, processing flows, interfaces, inputs, and 
Outputs. It will also address security, control and how 
the new system will impact on current operations. This 
CONCeDEldl" systems design ecdescri bes, how ine system iwi ll 
work. It will be best in designing the system to work 
backwards from the desired outputs. 


2.4.3.2 Prepare Narrative of the Design. The 
narrative will describe how the system will operate and 
what functions it will perform. It will provide an 


overview of the conceptual systems design and provide a 
rationale for options chosen. 


Review Conceptual Design Objectively by a Third Party 


The main purpose On such a review is to 
establish that the conceptual systems design answers to 
the approved definition of _the MIS (Section 2.4.2). 
Auxiliary jpurposes would be to ensure that the design is 
technically feasible and that, given the constraints, the 
best design options are considered and the optimum 
approach is used. This review will be presented to the 
Project Team. 
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2.4.6 


Refine the Master Plan 


7 Ws Rab Review Estimates. iiigdaght ofethey conceptual 
design, resource estimates will be reviewed and 
adjusted as needed. 


2.4.5.2 Refine Schedule. Its wikl Obes@poss bles ro 
refine the work scheduled and make the milestones more 
precise with firmer dates. If the MIS development is 


to be modular, each module should be clearly identified 
in the revised schedule. 


Review of the Conceptual Systems Design by User and 
Management 


2.4.6.1 Present Conceptual Systems Design to the 
User. The users will have an opportunity to review the 
conceptual design and cause modifications to be made. 
The Project Team will seek the users' concurrence and 
commitment for future cooperation during development and 
implementation. Having the conceptual design allows a 
clearer indication of how the MIS will impact. 


2.4.6.2 Review Refined Plan. The Steering Committee will 
review the revised schedule, resource requirements and 
costs. They will ensure resources can be made available. 
If there are major differences from the approved Master 
Plan these should be submitted to Senior Management for 
acceptance and commitment. This (step wetaiiordswtaan 


-Ppportunitys to halt-tdevelopmenG Of ethe*sMisStrbeteremmnt 


begins as its implications on the organization are now 
clearer. 


Detailed Design for Each Module of Master Plan 


Zak 


Complete Detailed MIS Specifications 


Zeodel sk Depict Outputs. All outputs from the system 
module will be identified in terms of content «and 
medium. For reports indicate data “Yocation “in "the 
report, secontent;, = (sequence. covals7. cOnterols® anda page 


separations. Similarly bon on-line video screen 
displays make screen layouts. For files passed to 
other modules the format, contents and documentation 
Should be produced. All of these will be done in 


conjunction with the user and each should be signed 
OL t-. The frequency, volume and distribution of outputs 
will also be considered. 


Zid s Lied Identify Processing Steps. This will describe 
what yeach: “major. processingemrunction ewhlli, do. If the 
function is to be done on computer these will serve as 
program definitions. 


Aen Es! Design the Data Base. The data base consists 
of those elements required for this module. The design 
involves defining the data elements and collecting them 
encosyWogical.. récords.: Besides details on the data 
elements such as size, mode, description and purpose, 
it is necessary to include security, privacy and policy 
considerations. 


Nas em Define Inputs. Define or obtain details 
concerning inputs to this system module. Tiss owe ie 
include the media, frequency, volume, source and 
contents. Any input forms should be signed off at this 
stage. The input will be separated into logical 


transactions. 


Ze. Loo Diagram the Flow of Data. This will be a 
chart depicting the flow of data through the system and 
it will be a means of communication of ideas between 
user © and ‘ftechnicall.. stafét. It will break down the 
processing into major functions. 


Review System Module Objectively by a Third Party. 


Ltampossible;, ian, objective third, party should review 
what was produced in Sections? 2.57! exytoummefines. the 
conceptual system design and advise the project manager 
ony, theyiqual 1tya jofie systemene; pus’ obtaining: The result 
of: this review may be a revision of the . conceptual 
design. 


Establish Final Resource Requirements. 


The detailed design of the module will enable more 
accurate estimates of resource requirements both for 
development and operation. Development would include 
hardware (computers, communications, CcC ay software 
(programs purchased Ors developed) and operating 
procedures. Based upon input, output and processing 
volumes the costs of operating the system can be 
accurately estimated. 


20.5 03.51 Refine Work Plan and Schedule. In view of the 
resource requirements established and the detailed design 
of the module the plan and schedule can be refined. At 
this stage commitments of technical support can _ be 
finalized. 


YASS ey Establish Final Estimates (Development ' and 
Operating Costs). With the refined work plan and resource 
requirements all cost estimates can be finalized. If the 
estimated cost is substantially more than the original 
estimate, development should not commence until the reason 
is determined and any necessary corrective action taken by 
the Steering Committee. 
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Perform Management Review 


The Steering Committee will review the systems module in 
light of the detailed design, its review by a third party 
and the final estimates. Such a review will allow a 
SION=0ft 4 byv aul concerned. Thissewpbh, also #signal the 
procurement of staff and equipment. 


Achieving Operational Status 


26 Oiark: 


2.6.2 


2.6.3 


Develop System or MIS Module 


The Project Team is now concerned with the development 
ebiort™. If the system is manual these activities consist 
of the development of procedures only, while an automated 
system would require programming as well. Both involve 
the review and finalization® of _the conceptual systems 
design as approved in Section 2.5.4. An important part of 
this task will be to apply all programming and operational 
standards and establish management control. Programs and 
procedures will be developed and tested internally with 
program and operational documentation being prepared at 
the same time. 


Complete User Training 


Zeenat Plan Training. Planning? for user? training, can 
begin in earnest once the conceptual design and schedule 
has been established. Thais * Planning» @iwhslslbe slden tx Ey, 
personnel, materials and content of the training. User 
‘involvement in performing the training is preferable. 


2.6.2.2 Conduct Training. The user training will require 
the preparation of all operating and control procedures. 
Training should also cover the responsibilities of users 
with respect to the system. This user training can only 
occur after detailed procedures for users have been 
developed and for best effect should occur just prior to 
the training being applied. 


Plan and Conduct the System Acceptance 


Once the conceptual system design is approved _ the 
systems test can be planned. It will require extensive 
test data and thus -must=- "be altocated=surhicienr 
resources. This test is the responsibility of the user 
who should prepare test data using any technical 
assistance necessary. The expected output must also be 


determined before actually running the test. Technical 
Stati. wi lie ard eine running thes Cesc arancd -ereCt i ying 
discrepancies aS soon as possible. The final systems 


test data should be retained for use during future 
systems' modifications. 


2.6.5 


Plan and Perform System Conversion and Implementation. 


2.6.4.1 Convert system. This will be necessary where 
there currently exists a system (manual or automated) 
which will be superseded by the new module. It may be 
desirable to do parallel processing if that is feasible. 
Files may have to be converted and new ones created. 
There must be controls to assure the integrity of these 
converted files. 


Ideally both old and new systems should be run for the 
same processing cycle and outputs compared. 


2eOe4e 2 Perform Final Implementation. The system will 
be turned Over to operating personnel and function in the 
operating evironment. THis’ turnover «wel Sincludé a 
Operating documentation, processing and date retention 
schedules. Some technical support may be necessary 
during the early stages of the implementation and prompt 
response to startup problems will increase the 
credibility of the system with the user. 


Evaluate Module after Implementation. 


This evaluation should occur 6=12 months after 
implementation. It will examine if the system appears to 
be meeting its goals and recommend any changes to improve 
this. A few month's successful operation can give 
accurate costs for operating the system. A by-product of 
this evaluation may be the lessons it teaches which can 
be applied to future projects and such information should 
be documented and distributed widely. 


The evaluation should be considered a necessary step and 
the development cannot be considered complete until this 
evaluation has been done. 
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Considerations 


In taking steps to achieve an MIS it will be necessary to 
consider how some of these steps can be taken. For example it 
is well and good to specify that documentation should be 
produced but what documentation? This and some other such 
considerations are addressed in the following sub-sections 
although these should not be considered as all the possible 
considerations nor an exhaustive discussion on any one of 


them. 


A Methodology to Obtain Information Requirements 


Ascertaining what is required for a MIS is not a trivial task 
nor necessarily an easy one. It ‘requires »'the?/ full 
participation of the user and the onus is on him to clearly 
articulate what is required. Itis~onlysaiternm this etask ehas 
been done that the MIS can be defined, designed, implemented 
and evaluated. There are many methodologies for determining 
information requirements and these range in sophistication 
from a few casual interviews to comprehensive systems to 
determine requirements. A review of such systems and a 
bibliography is given by Taggart and Tharp: (13). 


A method developed and tested by NWG is described in Appendix 
A. It consists in determining the organizational hierarchy 
(i.e. program classification structure) and, for each activity 
identified in the hierarchy, the information and thence data 
elements required. In addition there are provisions for 
entering definitions for terms at every level. A turnaround 
document is provided to enable a potential user to utilize the 
stated requirements of another user to help build up his own. 


Security, Privacy and Confidentiality 


The terms security, privacy and confidentiality are often 
lumped together and, unfortunately thought of, as part of the 
same lump. For purposes of discussion they will be defined 
here as: 


(i) Security: The protection of resources (including data 
and programs) from accidental or malicious modification, 
destruction or disclosure. (10) 


(11) .\Privacy: “In ‘an informational contextiG is *the social 
expectation that the individual will have some: 


- say on how information about him is used, to whom it 
is communicated, and how it influences him; 


- protection against unwarranted harm because of the 
functioning of some record keeping system and be 
treated fairly by such systems; 


- protection against unwelcome, unfair, or intrusive 
collection of information. (11) 


This is predicated on the individual “owning" information 
about himself and having some say in its use. 


(iii) Confidentiality: An attribute of the information which 
describes the desired level of accessibility. 


Security itself can be broken down into components such as: 


a) System Security. The state of a computer system 
(hardware and software) that makes it possible to 
provide reasonable assurances of security. System 
security presupposes that appropriate steps are taken 
for physical protection of the computer, for 
Operating and maintaining the system, and for 
identification and authentication of users of the 
system. (10) 


bb)» Data Security The protection -of the.datagfirom 
disclosure or loss of integrity. 


The advent of large scale data banks with personal data, 
advances in computer technology which provide the means to 
more eaSily access these data banks, and an increase in public 
sensitivity to concerns about security, privacy, and 
confidentiality conspire to render these as very important 
considerations in any MIS. Therefore the concepts and design 
of an MIS must consider very early in the planning the 
required degrees of security, privacy and confidentiality and 
build these into the design. Within the planning framework of 
this paper these considerations should be recognized and 
defined early in the Review and Evaluation Phase (Section 
PEASY Ne 


To accommodate these considerations after the Detailed Design 
Phase (Section 2.5) may prove to be very expensive, awkward or 
simply impossible. 


It is not the intention of this section to thoroughly discuss 
security, privacy, and confidentiality but to acknowledge its 
importance and place in achieving an MIS. The reader is 
referred to the recent report to BC Attorney General and BC 
Systems Corporation by Dennis Hartman (ll) for a _ thorough 
discussion on privacy. Search Group Inc. has- recently 
published a bibliography on these subjects (12). 


Documentation 


3.3.1 Purpose 


Documentation for a system is necessary to: 


- Respond to user requirements by describing how a 
system meets their objectives; 

- Give general and then specific details on what the 
system does and how it does it so that the user 
can judge its output; 
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=» .opecriyphow; EO, Operate: the systems 

- Assess whether the system (developed locally or 
obtained by transfer) can be accepted; 

- Provide sufficient detail to maintain the system 
(i.e. correct errors, enhance, change due to 
external circumstances); 

- Estimate cost of operation and maintenance; 

—- ‘Transfer -the system to other users. 


Documentation for any system is recognized as being 
extremely important: but it is all too often,incomplete 
and inadequate for what is needed. With respect to 
computer systems the developpers are often loathe to 
fully document what has been produced and would rather 
go on to new problems and assignments. Therefore in 


developing any system Ite is important that 
documentation standards be established early and then 
enforced. Documentation which is produced almost 


concurrently with the systems development is preferred 
Since it is easier to produce this way and standards 
are more likely to be enforced. 


Areas of Interest 


The documentation for any system should address the 
following areas of interest: 


(i) System Overview. This allows the reader to gain a 
global understanding of what the system is, 
generally the approach behind how it operates and 
the relationship of its components and files. 


(ie watame(inpit, ~<Output,, “Internal » eilecos This 
explains in detail the definition, coding, data 
concepts of data elements and their organization 
into files. The volume, frequency and file medium 
is addressed and outputs depicted in some detail. 
If a data base management system (DBMS) is part of 
the system its schema (i.e. organization) and 
other attributes should be described. 


(iii) Detailed Description. This would include detailed 


descriptions of modules and sufficient information 
to allow installation of the system and its 
maintenance (correcting errors, enhancing, 
customizing). 


(iv) Operations Documentation. This should furnish the 
user with the instructions on how to operate the 
system. As well, a user guide will show how to 
interact with the system and use it to advantage. 


(v) Other Considerations. These include security, 
privacy, and confidentiality provisions of the 
system. Other particular features would concern 
the system's transferability and systems support 
(@specially if it isesuppliedsexternally). 


Documents 


There are no universal standards for documentation but, 
as Spodmteds mouth ineasectionsi2747a2 A standards for 
documentation for the development of a MIS should be 
established before the system development begins and 
then «these "must «vbe GienBorced. The format = and 
Organization of systems documentation will therefore 
vary but a well documented system should contain the 
following pieces: 


- System Overview, 

=1 *FlowsCharts ="gqeneral  vandsspecitic, 

- System and Program Descriptions, 

- Program Listings (not necessary if programs are 
maintained externally), 

= vVRecorditbayoutssornschemavior lalleirices;, 

- Data Concepts and Definitions, 

- Operations Manual for running the system, 

- Log Books and other record keeping devices to 
operate the system in production, 

- Users' Manual on how to use the system. 


NWG assembled some specifications concerning system 
documentation and these are shown in Appendix B. 


3.4 Technology Transfer 


Introduction 


While =the» ecosty, of ¥pelectronics 4 and; thus’ *'computer 
hardware has been falling, the cost of manpower and 
thus the cost of programming or computer software has 
been rising. These trends can be expected to continue 
so that computer software is becoming an increasingly 
expensive commodity. However, much computer software 
has been developed in recent years to address the area 
of justice systems and this can be shared. This effort 
has resulted in several well-documented systems and 
also in some systems, features especially designed to 
facilitate systems transfer. 


Because of these trends and the availability of 
transportable systems, the transfer of technology to 
develop any MIS must be seriously considered. In’ face 
a smaller agency cannot hope to completely devise its 
own MIS alone because of the high cost of doing this 


and the scarcity of knowledgeable people. One is 
always tempted to state that one's own requirements and 
environment are too "“unigque" to use the work of 


others. It is easy to adopt an "NIH" (Not Invented 
Here) “attitude, an, affliction jarticularly prevalent 
among systems and programming people. 
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The transfer of technology should be encouraged for the 
following reasons: 


(a) Increasing costs. These result from higher wages, 
increased complexity of problems, higher 
expectations of users, increased scale of problems 
and a higher sophistication possible in computer 
science. 


(b) Higher rate of change in society. It is hard to 
justify development projects which would extend 
more than 2 years. Technology transfer is one 
means to speed up development. 


(c) Possibility of greater perspective. Technology 
transfer increases the number of perspectives and 
different ideas which can be brought to bear on a 
problem. The very act of seeking outside technical 
solutions may broaden the outlook on the problem 
and steer one clear of excessively complex solutions 
that may be concocted in splendid isolation. 


(d) Compatability. Transfer of technology can result in 
more compatible systems and greater ease in 
exchanging information produced from these systems. 
Similarity in systems also can result in mutual 
backup in case of problems. 


What is Technology Transfer? 


Technology transfer can occur at 3 levels: 


(a) Conceptual. Concepts or ideas are transferred 
although their implementation may differ. Examples 
in the Justice area could be having information 
based on the offender in corrections, the use of 
UCR- offence’ classification in various “police 
information systems. 


(b) Design. Specifications and procedures for a system 
could be transferred but not computer programs. 
The OBSICS model for Corrections is an example of 
this type of transfer wherein the procedure, data 
elements, specifications for modules are 
transferred. 


(c) Operational. Actual computer systems are 
transferred. This would include software and 
detailed procedures. 


Technology transfer has been effected at all levels but 
the transfer gets progressively more involved as one 
goes from (a) to Gen. For example much’ more 
documentation from the donor and much more learning by 
the recipient is required for a (c)-type rather than an 
(a) type transfer. 


Transfer can be done by: 


- accepting something free, 
=) DOELrOwing; 

- bartering, 

== renting’, 

-SOuUy ing, 

- or even stealing. 


Seldom is anything ever totally "free of charge" 
including, fLreshygairessoe that technology borrowed, or 
transferred free of charge, or stolen will still cost the 
user time to adapt. It will undoubtedly carry the caveat 
"user beware" and it will be the user's problem to make 
it work. 


Bartering puts the user in a slightly stronger position 
in that he can support and assist in the technology he 
has given in exchange for similar support for what he has 
received. 


Renting technology can free the user of much of the effort 
in implementing and maintaining the technology transferred 
The user can avail himself of the enhancements as they 
OCCUL. However, this may lead the user to external 
dependencies which may not be acceptable. It may be 
artficult, to tailor the technology; <acquined..in, this .way.to 
the user's particular needs. Dependence on the lessor to 
provide the technology may lead to internal developmental 
stagnation. 


Buying technology can allow the user to shop, compare and 
demand the technology he wishes. However, the greater the 
amount of customizing demanded the higher the cost. Once 
the technology is acquired the user may choose to have it 
maintained by the vendor with possibly undesirable external 
dependencies or build up internal expertise. Either way 
there is a continuing cost which should also be considered 
in addition to the purchase price. 


FOr. aw user to beeing .control) of, the, technology, transferred 
him, he must acquire a depth of knowledge up to the level 
of the technology transfer. For example if the design is 
being transferred the user must understand the concepts 
Underlying it, “tf 1t is an Operational technology transfer 
the user must understand the design considerations. 
Although there are benefits in this transfer process, it is 
not magical and cannot be viewed as a black box which will, 
unaided, answer to the needs. 


ALS) 


3.4.3 Benefits of Technology Transfer 


The most compelling reason to consider technology transfer is 
its potential Saving» for the cost of development @Oinel I7Guere 
LEAA attempted operational technology transfer for six sites 
(6) and the following table is an estimate of potential savings 
which can be realized in the justice environment. 


Savings 


iype cof Transter 


Types of Costs 


Design 20-40% 
Coding/Testing 0) 
Documentation 15% 
Maintenance 0 


Obviously an operational transfer has greater potential for 
saving especially in coding the software. However, it requires 
more learning by the user, and a more involved transfer process 
as well as more adaptation by the user to the technology being 
received. In contrast the conceptual transfer could be done 
simply by reading some documents and,interestingly enough, 
there are possible savings here. 


3.4.4 Conditions for Technology Transfer 


Tasks involved in technology transfer are shown in Figure 2. 
This procedure is geared “particularly (“to transier Wat the 
operational level but it could apply to technology transfer at 
other levels. Implicit in the technology transfer process is 
adequate planning and ae sufficient requirements’) analysis. 
Especially with operational technology transfer there should be 
a user group at the beginning to be responsible for these tasks 
and one should count on heavy user involvement in this 
process. It. 1S necessary to “fully “identity ‘and’ *eVarify: wai 
constraints (political, environmental and technical), in order 
to be able to identify feasible technology transfer. Without 
adequate documentation effective transfer will be impossible so 
this too is a necessary prerequisite. 
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A few general commandments with respect to transfer 


Ges 


Tl. 


Never be the first recipient of the technology 
unless =your wish to share Min =the sainatl debugging, 
testing and shakedown. 


Do not adopt revolutionary technology without a 
backup or fall-back position. 


Never accept technology unless you are prepared to 
fully test and evaluate it. 


Treat the transferred technology as if it is your 
own because in case of problems it will be regarded 
as such. 


Cost —- Benefit Analysis 


Introduction 


In developing a MIS there are several steps at which an 
evaluation and decision must be made by management. 
These include review of the Master Plan (Section 
253.10), *ceview “of the 7 Conceptiats des tgnala( sect von 
2.4.6), review of detailed design (Section 2.5.4), 
past-implementation evaluation (Section 2.7.5), and 
others. 


To evaluate and make decisions management must have 
quantitative information concerning costs and expected 
benefits. However, obtaining rigorous cost benefit 
analysis for an MIS is not easy so that it may not be 
attempted, or, if done, performed in such a way that 
the results are suspect or inconclusive. 


This Section will discuss briefly what a cost-benefit 
analysis is, its purpose, and points to consider that 
should be addressed in doing one. Much of the material 
is adapted from the King and Schrems paper (14) which 
contains a more thorough and detailed discussion and 
this paper has a bibliography. 


32D Purpose 


The cost-benefit analysis can be used as: 


a) A planning tool to assist in choosing among alterna- 
tives and allocating scarce resources among 
competing demands; 


b) An auditing tool to perform evaluations or follow-up 
On a project; 


c) A way to demonstrate "quantitative" support to 
politically influence a decision. 


All too often the third use is the most common although 
if the world were made up of rational, objective 
people, only the first two uses would be legitimate. 
in any eventiya., cost-benciite analysiss. which: »would 
produce information which the decision-makers can use 
with confidence is in itself an undertaking and for 
some large systems a major exercise. It will require 
skills in producing the analysis and in interpreting 
the results. 


3.5.3 Characteristics of Cost-Benefit Analysis 


For comparative purposes costs and benefits must be 
expressed in some common unit such as dollars or 
perhaps man-years. Costs represent the resources 
required to procure and operate the MIS and could 
represent the price of equipment, rent, salaries for 
developers and operators of the system. Benefits could 
typically represent cost savings, cost avoidance, 
improved operational performance and "intangibles". 
Intangibles may refer to improved information for 
decision making, better control, better service, or 
enhanced morale. Theserdi fiaculteyawith’ intangibles is 
that they cannot be easily quantified and used in 
determining the cost-benefit ratio. Ideally they could 
be ignored if the tangible ones are sufficient or 
else the manager could judge whether they are worth the 
extra money necessary to make the benefits equal 
resources. 
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In considering alternatives or making a go-no go 
decision concerning an MIS the decision-maker will be 
seeking the lowest value for the cost/benefit ratio. 
To determine this accurately one must standardize the 
costs and benefits. Thus one must consider: 


i present value of costs and benefits since the value 
of future benefits should be discounted by the 
current interest rate; 

= Inflation GEEects if possible; 

= Same time period for comparisons; 

= all overhead and hidden costs; 

= the effects of double counting or omitting costs; 

- unrealistic predictions of costs and benefits. 
COSES (are SditEucuSt seto ¢ control, ‘and? Shbenesues 
dveracult to -achreve. 


3.5.4 Conducting a Cost-Benefit Analysis 


The five main steps are: 


Gi)P "Selectrng™= an ranalyst tor sos thes cost=benerRre 
analysis. This may be from in-house 
personnel, consultants OG from another 


organization. 


(ii) Selecting alternatives for study. The number 
of these will be limited as far as possible 
with the risk that the best one may not even 
be considered. 


(iii) Identifying and measuring all costs and benefits. 


(iv) Comparing alternatives. Costs and benefits must 
be in common units. 


v) Performing the analysis. This involves first 
selecting the decision criteria then applying 
the comparison. 


Thevyractual \carrying Jowt Sot (these activities is fraught’ with 
problems in identifying all costs and benefits and in 
assigning quantitative values especially to the less tangible 
benefits. However it is a necessary exercise if decision 
Making Other than political» grounds 1s) tomoccur. 
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APPENDIX A 


NWG Methodology for Identifying Information 


Requirements in the Field of Justice 


Introduction 


This particular methodology for determining information 
requirements was developed by the National Work Group on 
Justice Information and Statistics (NWG) during 1979. It was 
in response to a request to develop such an approach at the 
Federal Provincial Advisory Committee (FPAC) conference of 
Janianry; = L979. This was felt to be a necessary and primary 
task in attaining better information in the field of Justice. 


The methodology was developed with the following underlying 
principles with respect to justice information: 


(a) National statistics should be a by-product of operational 
systems statistics; 


(b) Common data definitions and concepts are necessary; 
(c) Information needs must be fully defined; 


(d) Local authorities must be responsible to collect and 
assemble their own data regarding information requirements. 


The methodology to be developed was constrained by a lack of 
large amounts of resources for the exercise, the necessity to 
deal with 13 governments and a variety of organizations within 
each government. As a result a modular format was developed 
and a strategy proposed whereby the results supplied by earlier 
respondents could be utilized by subsequent respondents. 


Al 


A2.0 


A3.0 


A4.0 


A2 


Application 


The methodology attempts to collect hierarchical information 
concerning the organization's programs. This hierarchy uses 
the terms program, subprogram, sub/subprogram and_ then 
identifies activites performed. For each activity it seeks 
to determine what information is needed. The information can 
be divided into constituent data elements, and for each of 
these,the uses for which that element is needed are recorded. 
In addition definitions can be given for all levels in the 
hierarchy as well as for information and data elements. 

A series of forms (Figures 3-8) are enclosed. These forms are 
the vehicle which permits the responding agency to describe 
its program structure, activities and information needs down 
to the data element level. Turnaround documents are also 
enclosed (Figures 9-10) which permit verification of the 
information given and allow a subsequent respondent to build 
on the work of previous respondents. Directions on how to use 
these forms are given in Section A6é.0. 


Using the Methodology 


A thorough definition of requirements needs the very active 
participation of the potential MIS user. This participa ron 
would begin by the user completing the forms. Where there are 
several user areas a central group (in this case NWG) may need 
to consolidate and coordinate this information gathering 
activity. To save work one user area would begin the exercise 
from scratch, by completing torms, O1C, 01D 7 020 202) e0SCy. va. 
This information would be put into computer-readable form by 
the NWG then fed back to the respondent for confirmation and 
cOrnec tion. The NWG would then furnish a second user area 
with turnaround documents (see Figures 8-9) containing this 
information. The second agency could simply indicate whether 
the information is applicable, available and if they agree. 
If they do not agree they could enter their information on the 
OF G inal? pEorms. In this way the requirements of subsequent 
users are built up from others and the response burden is 
lessened. 


Analysis of Requirements 


The forms allow the group analyzing requirements to code 
classification numbers. This would be done in a logical 
systematic fashion to expedite subsequent analysis. 


Form sease. and «flexibility, of. analysis and because. of ..the 
anticipated amount of information which could be expected from 
thaisi.exercise of. defining, requirements,, it may» be useful. to 
put the information into a machine-readable form. Once this 
is done the following operations are easily accomplished: 


- manipulation (sort, merge, select) to support analysis of 
this information; 


- production of turnaround documents from which further 
information may be elicited from respondents; 


- updating as new information is received; 

—. feedback-of .information,for.confirmation; 

- retrieval of information to satisfy external requests; 

-. determination ofsstatus of thewsinformation: bank, i.e. 
who has reported, amount of agreement on 


definitions, use of data elements, structure; 


- a tool to facilitate getting agreement on common 
terminology, concepts and definitions. 


mie sexpected results =trome taking this approach) are’: 


(a) Explicit identification of information and 
data elements needed in the MIS; 


(b) More uniform concepts and definitions. This is fostered 
by having one agency build on the work of another. The 
classification numbering can allow manipulation of 
information to bring together similar data elements and 
permit the chance to resolve inconsistencies. 


(@)itiidentification’ of pinformatione whichuican, be..shared by 


activities. All activities which require a particular 
data element can be identified. 


A3 


A5.0 


A4 


Definitions 


The forms for inputting information requirements are shown in 
Figures 3 to 10. The terms as used on these forms are defined 
below: 


Program: A component of the justice system with specific 
(PGM ) jurisdictional responsibility (e.g) Poliee; 
Counts 7; sCorrections:)< 


Subprogram: A subdivision of a program which categorizes the 
(SUB PGM) various services provided within the program. 
(e.g ¥PGMsy Pol rce; YSUBEPGM. Patroim. 


Sub- A further subdivision of a subprogram thus 
Subprogram: allowing for sufficient levels in the 
(S/S PGM) hierarchical structure to fully describe the 


program, structure: i¢e.g. BGM: Adult Corrections, 
SUB PGM: Probation; S/S PGM: Investigation). 


Activity: An“activity iIs“a’ particular *formeortendeavour 

(ACTI ) undertaken to meet the objectives of a program, 
subprogram or s/subprogram. (e.g. Adult 
Corrections, Probation, Investigation, 
Presentence Reporting). 


Information: A quantitative or qualitative factor that carries 
(INFO) some facts or knowledge. (e.g. Socio-economic 
background, arrest ratio). 


Data. The smallest consistuent of information (e.g. 
Element: income, number of policemen, age). 

(DATA) 

Level: The level of the entity on the forms 

(LEV) (classification ‘or <dehinttion) oh i benwwilil have 


values 1 to 6 depending on whether the entity is 
a program (LEV=1) or a data element (LEV=6). 


In addition to determining the program hierarchy to which a 
data element may be related, Form 3C (Figure 6) also indicates 
the functions or uses for which the data element is required. 
These functions are: 


Operations: On a regular basis to carry out day to day 
(OPER) functions and activities in each area of 
responsibility (e.g. records, documentation). 


Administra-— 
tion: 
(ADMIN ) 
Planning: 
(PLAN ) 


Control: 
(CONT ) 


Statistics 
Local: 
(CSie 5 @ Ce) 


Statistics 
National: 
CSTs INAT) 


Legislation: 


Research: 


Input: 
(INPUT ) 


Other: 


These 


categories 


EOL the establishment of 
accounting and to 
evaluate programs. 


and 
and 


procedures 
implement, control 


For forecasting needs in areas of resources, 
including finances, manpower and facilities (may 
be dependent on policies). 


the emutilizatéion! tandsallocation of 
resources. This may be considered operational 
Management and is information which permits 
Management to exercise its control. 


To monitor 


For summaries of activities which are required 
On a regular basis to support any number of 
local functions such as operations, planning, 
control, administration and evaluation. 


To permit interprovincial and interterritorial 
comparisons. These statistics would usually be 
more general than Statistics Local. 


To fulfill requirements stated in an act of 
legislation (e.g. Census Act requires a count of 
voters) or data to monitor or evaluate 
legislation. 


By policy planners to evaluate or plan programs 
or by the research community to pursue research. 
It may be advantageous to review requests from 
researchers which have been received in the 
past. 


By another component of the justice system for 
any number of functions (e.g. case tracking). 


For other purposes than previously stated. 


may not be mutually exclusive. Te*~is 


probable that some data elements will be required to provide 
information to support more than one function and the form, 
03C, permits this to be indicated. 


A5 


A6.2 


Ao 


Forms 


Completion of Forms 01C, 01D 


Form 1C identifies the programs, subprograms, sub-subprograms 
and activities within a given area of the justice system such 


as “police, adults courts) or sadulitgrcorrections. Within 
different jurisdictions some program activities will vary as 
the responsibility of the organization varies. RY » is 
essential to associate definitions (Form 1D) with each 


program, subprogram, sub-subprogram, and activity to ensure 
that all . mesponsitbidity Vareas™ arericlearly ‘presenved,™ thiac 
comparisons can be made, and differences are recognized. 


Sample forms (see Figures 3,4) provide a cursory illustration 
off Lone, programs Probation iS examined in terms of both 
investigation and supervision activities. LES” = Se meet 
arbitrary breakdown, chosen only to illustrate a few of the 
functions of a probation system. 


On example Form O1D (Figure 4) Presentence Reporting is 
defined according *to the “Canadian Criminal *Coder=(e2Gre.) 
Section A66 Zia). Where» «such ‘a’ /definitdon vexistsalin) the 
Gruiminal “Code, it’ may be preferable ‘to’ reference only the 
C2G3C. sections 6o2i(1)x ForsiProvincialsLegaslation this will 
also be acceptable, given that copies of the relevant 
legislation or section of the legislation are attached to 
facilitate reference. 


Forms 02C, 02D 


Form 02C provides a vehicle to both inventory and define the 
information which is required within each activity. 


Presentence Reporting, for example, may require information as 
illustrated on example Form 02C (Figure 5). 


On Form 02D (Figure 6) the information needs are defined for 
Presentence Reporting to provide detail on the kinds of 
information required at this stage of the process. 


When information requirements overlap from one activity to 
another it is suggested that on form 02D these be identified 
by aSSigning reference numbers to each information requirement 
which will occur again. When the information need does occur 
again simply repeat the appropriate reference number. 


A6.3 


Forms 03C, 03D 


Form 03C serves two critical functions: 


- To provide a framework for listing the data elements 
required to.) iprovides tthe Sintormationwsto: support)” each 
act vary; 


y eloy haghbight. «the -Gunctions..0r, uses,.ofiethe, information by 


means of placing X's in appropriate functions (see Section 
NonOwe 


The data element serves as the basic building block of this 
requirements analysis. By means of its classification it can 
be associated with various information and activities and be 
found in more than one program hierarchy. The classification 
Will also allow similar or identical data elements to be 
identified and duplications in definition and nomenclature to 
be resolved. 


Turnaround Documents 


The turnaround documents present the information received on 
Loumsyole; OLD, ~02Ci oO 2Ds 0367 403D lum asueadily “readable® form 
which allows the respondent to indicate applicability, 
availability or agreement with information supplied. 
Turnaround Document #1 (see Figure 9) is used for data 
elements (Form 03C) and the accompanying classification 
information (Forms O1C, 02C) while Turnaround Document #1 - 
Definitions (see Figure 10) is for displaying definitions 
(FormstO0D7302D,003D)..- Both@doocuments Indicate wan) originator 
from which the information was compiled and a respondent from 
whom additional information is being elicited. 


A6.4.1 Turnaround Document #1 (Data Elements and 
Classification) 


Thee stitale: Vat "the-step Vof*‘each "page ‘refers to the 
program-subprogram-sub-sub program with its 
classification code. The respondent is identified with 
the date at which this information was sent. The 
originator's' date isthe date’ at ‘which this” current 
information was compiled. For information purposes 
the respondent and originator may be the same and this 
document is employed in a slightly different manner. 
The body of the document is organized by activity and 
then by information then data element. This permits 
easy distribution to relevant parts of ehe 


organization. The first number under NWG Use is a 
line sequence number and the second part of the coding 
assigned by NWG. Indentation allows one_- to 


differentiate between activity name, information name 
and data element name. 


A7 


A8 


The applicability (APP) and availability (AVA) 
columns should be filled in by the respondent with a 
Y%, (yeshiror ALR (no)? Applicability “1ndieatess 1c. the 
activity, information or data element is relevant or 
applicable to this particular sub/subprogram. Where 
the respondent and originator are the same (i.e. 
forms being used for confirmation) the applicability 
column is redundant. In that case each component of 
the justice system could look at the information 
Submitted by other components and answer Y or N under 
APP to indicate if the information is also applicable 
to their component. The availability (AVA) indicates 
if. the activaty, ) information: or, datagrelementl es 
readily available in a useful form with sufficient 
accuracy and timeliness for the respondent's 
activity's needs. 


The provincial summary on applicability and 
availability summarize for the respondent’ those 
provinces or territories who have by this’ time 
indicatéd Yo for) gAPP Or JAVAS) Lomwith tetractaiva ty, 
information or data element. 


The information use functions (applicable to data 
elements only) refer to how the originator filled in 
the “uses“ jin formv03c. Here the originator could 
indicate with an X up to 10 different uses for which 
the data element was’ required. The turnaround 
document indicates by a list of numbers (1 to 10) 
which uses the originator had indicated as follows: 


Le OPER. Operational 

2. ADMI. Administrative 
Sr PLAN. Planning 

4. CONT. Control: 

5. SP e LOG. Local Statistics 
Gis Si NAT. National Statistics 
Tac LEGI. Legislative 

Si RESEA. Research 

OF INPUT Input to another 

activity 

LOZ OTHER Other Uses 


The respondent can indicate agreement with these by 
leaving them as is, add numbers showing additional 
uses Or cross Out numbers which do not apply. 


If the respondent wishes to add further activities, 
information or data elements, this may be done using 
OWL in al pL EOrM Siu, Ore Cy OSG, The forms can also 
indicate the respondent's program, subprogram and 
s/subprogram structure. 


A6.4.2 


Turnaround Document #1 (Definitions) 


This document provides a display of any entity 


reported (program, sub-program, s/sub-progran, 
activity, information or data element) with its 
definition. It provides the respondent a means to 


confirm the information, agree or disagree with the 
definition and to note which provinces have accepted 
the definition. 


As with Turnaround Document #1 (Data Elements’ and 
Classification) the title at the top of each page 
refers to the program, sub-program, sub/sub-program 


with lts. .classitication. codex The respondent is 
identified and has the date when this information was 
sent. The oOriginator's data is the date when this 


current information was compiled. For information and 
confirmation purposes the respondent and originator 
may be the same. 


The applicability (APP) and correctness (CORR) columns 
should be filled in by the respondent with a Y(yes) or 


N(no). Applicability describes if the concept is 
applicable to that portion (i.e. program, activity or 
information) of the criminal justice system. The 
provincial summary indicates those provinces’ or 
territories that have accepted the term as 
applicable. Corrections allows the respondent to 


indicate if he agrees with the definition as 
presented. If not the respondent may submit his own 
definition using forms 01D, 02D or 03D (whichever is 
applicable). If the respondent and originator are the 
same (confirmation mode) errors in the definition 
could be altered directly on the document. The 
provincial summary indicates which provinces’ or 
territories agree with this definition. 


Sorting of these documents permits one to list 
multiple definitions for the same entity with every 
province or territory that has responded. 


It can also furnish a cross-reference if the entity is 
a data element or information. For data elements it 
will indicate by name the information and activity to 
which the data element belongs. For information it 
will indicate by name the activity to which this 
information is related. 


The turnaround document may also indicate "previously 
defined" where the originator had already defined it 
elsewhere. If the definitions are presented in an 
alphabetical order within the program, the actual 
definition will occur followed by the same activity, 
information or data element name which will contain 
"previously defined". 
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B1.0 


STANDARD SYSTEM DOCUMENTATION 


General Overview 


This reports deals with the technical documentation that should 
accompany any data processing system that has been completed and 
set up. The purpose of this documentation is to permit quick, 
efficient use of such processing systems by personnel who are 
properly qualified, but have not taken part in their development. 


This report is derived from the documentation standards currently. 
used by Statistics Canada, and is divided into three sections: - 
systems documentation on the systems themselves, data 
documentation, - operations documentation. 


Section B4.0 deals with the procedures to be followed in 
transferring systems from one facility to another. 


Systems Documentation 


Bl.1l System Overview 


A description of the purpose and characteristics of the 
system, including: 


- purpose, 

=a general. functions, 

= jMEGSSome Ussiesh- 

we OCSCrUDtionsoOf a HpuES, 

= descrrpuron of ‘outputs, 

- agency responsible for development. 


Bl.2 General System Technical Description 


- language(s) used, 

- software requirements, 

- computers, 

- terminals, 

= number® and’ size of programs and files, 

- management software usage, 

- access methods, 

- data security methods, 

—- protection and restarting procedures in case of failure. 


Bl.3 Detailed System Design Description 


Description of the technical design and methodology of the 
system: 


Bl 


B1.3.1 System Component Specifications 


- overall purpose of subsystems and modules, 
structure and interaction of subsystems and modules 
(flowchart), 

- method chosen, 

terminology, standards and conventions, 
denomination of inputs and outputs, 

- limits and constraints of different entities. 


l 


Bl.3.2 Job Stream Specifications 
B1.3.3 Individual Program Specifications 


- purpose, 

- program characteristics, 

- input and output identification, 
= identiiicationm of uta bueresc: 


Bl.3.4 Cross-reference Index of Programs, Jobs, etc. 
Bl.4 Program Descriptions 


Processing programs must be described as follows: 


- main program functions, 
- environment such as operating system, language used, etc, 
- Control parameters such as: "PARM" control card parameters, 
- indication of input and output files used, 
- processing flowchart, 
- description of decision tables, pseudo-codes, etc, 
- the program itself, with structure and notes to 
facilitate understanding, 
- list of conventions used for variables. 


B1l1.5 Methodology 


The theoretical approach to system design should usually be laid 
out and explained. For example, for a model of population flow 
through a given system (court, prison, etc.), the selected 
approach should be specified (eg. offender based). 


B2 


B2.0 


B2.1 


B22 


B2.3 


B2.4 


Data Documentation 


It is indispensable to have separate documentation for data 
produced and/or handled by the system, particularly in the case 
of information systems. This documentation consists of: 


See rLint tron Of data concepts, 
—siteidescriptions; 

= record descriptions, 

- cOding schemes, 

- data set descriptions, 

- report and file/item cross-reference. 


Definition of Data Concepts 


This includes the description of data-represented entities, 
logical groupings of data and their properties. 


File Descriptions 


These descriptions include: 


- reference name, 

- general statement of file content, 

— summary description of file records and relationships 
between records, 

- relationships between files, 

- reference names of key fields, sort keys and record type 
indicators, 

“muy PesOLetite Organization, 

- file sequence. 


Record Descriptions 


These include: 


- reference name, 

- list of reference names, 

- position of each item in the record, 

= format of each item, with the convention used (i.e. COBOL 
OGBePEE) > 

- for coded items, a coding scheme reference and, if 
applicable, the value corresponding to the codes, 

- brief description of items having names that are not 
self-explanatory. 


Coding Scheme 


The corresponding value should be given for each code. 


B3 


B2.5 


B2.6 


B3.1 


B3.2 


B4 


Data Set Descriptions 


These contain all information required for access to and use 


the data contained in the data set. 


They include: 
- data set name (DSN), 
- volume serial number, 


- name of file to which the data set belongs, 


- brief description of content, 
- creation date. 


Report and File/Item Cross-Reference 


This cross-reference provides a means 
file or report at any given time. 


It usually -consists “of "ay computers zed 
items, files and reports. 


Operations Documentation 
Operations Manual 


The Operations Manual is intended for the personnel 


operating the system. It should contain: 
- table of contents, 

- system overview, 

- system flowchart, 

- production workflow, 

- jobstream description, 

- list of catalogued procedures, 
- operation environment, 

- data set management guide, 

- sample documents, 

- message list, 

- file descriptions, 

- record descriptions, 

- coding scheme. 


User's Guide 


of jlocatingy any 


BES Re Or 


This guide .contains,,; the. documents, ,sequired 


user of the system. Ine Danticolar 
following: 

- table of contents, 

- system overview, 

- system flowchart, 

- production workflow, 

- operation environment, 

- data concepts, 

- file descriptions, 

- data set management guide, 

- message list, 

- language reference guide, 

- methodology, 

- detailed system specifications. 


Lesashould 


of 


item, 


the various 


by... the 
contain 


end 
the 


B3.3 


B3.4 


B3.5 


B3.6 


System Flowchart 


This flowchart is a graphic representation of the processing 
system. It describes all major manual and _ ~mechanical 
functions of the system. 


This representation consists of flowcharts diagramming the 
functional relationships of the system from the top down, i.e. 
from the highest aggregate level down to the lowest level, 
which is usually a single phase in one of the processing 
programs. 


Production Workflow 


This workflow specifies the nature and order of the actions 
required to run the system. It is generally prepared for each 
level of interaction with the system. A production workflow 
will include: 


- production scheduling, 

- file handling procedures, 

- manual and clerical procedures, 

- job submission procedures, 

- time sharing type commands and symbolic parameters for 
controlacards. 


Time sharing commands, will be described, as will the symbolic 
parameters if they are used on control cards. 


Jobstream Description 


Each of the operator's activities on the computer should be 
described in clear, non-technical terms. The description will 
include: 


- purpose of activity, 

- relationships to other procedures, 

= limitsor-iconstraints: appl yingitomthesactiy ity, 

- frequency of the event, 

- function of each procedure, 

- input descriptions (control cards, files, tables), 
- output descriptions, 

- list of prerequisites before running the job. 


Catalogued Procedures 


Catalogued procedures are used to obtain more rational and 
efficient control card organization. They include: 


- at the beginning of each procedure, a comment block 
containing the name and function of each procedure and a 
list of parameters used, such as keywords and default 
values 


i after each "EXEC" card, a description of the functions of 


the step. 


B5 


Si any | 


B3.8 


B3.10 


B6 


Operation Environment Description 


The purpose of this section is to describe the hardware, 
software and human resources required to run the system. 1B 
will include descriptions of the following: 


- hardware, 

- software (list of application programs or packages such as 
EXTRACTO), 

- personnel skills required to run the system, 

- some elements of accounting data (CPU cost, disk use, eke.) 

- decision-making points and communication lines to _ be 
followed during production, 

- policies relating specifically to that application. 


Data Set Management Guide 


This guide contains data set control procedures. it-usually 
contains: 


- general data set organization, 

- data retention periods, 

- data and data set naming conventions, 

- data support media (paper, tape, disk, etc.), 
- the name of the Data Set Manager. 


Message List 


The user should be supplied with the list of messages from 
the application program(s). This list usually includes: 


- the message as produced by the machine, 
- an explanation of its circumstances and implications. 


These messages inform the user of the processing result and 
some operating parameters (record numbers). Messages of time 
sharing. origin may *also °beq included. Messages from the 
operating system are generally not included. 


Language Reference Guide 


This guide describes how to use parametric type languages, 
(i.e. high level languages only requiring certain operating 
parameters). This guide will include: 


- brief language summary, 

- detailed description of syntax and semantics (language 
architecture, notation, syntax and definition of terms), 

- message list, 

- concrete operating examples, 

- limits and constraints of the language and some 
considerations regarding its performance. 


Bsc) 


B3.12 


B3.13 


B4.0 


Training Manual 


A training manual may be necessary in the case of a highly 
complex system or when a large number of persons are likely 
to be using the system. A training manual generally requires 
re-arrangement of documentation materials for teaching 
purposes. 


Problem Notice 


Separate problem notices should be established to describe 
difficulties encountered during the installation and start-up 
of a system and offer possible solutions. Solutions should 
be recorded when implemented. 


Sample Documents 


All documents such as questionnaires, waybills, input-output 
documents, control documents, should be attached to the main 
documentation. 


System Transfer Procedures 


Although transfer procedures are not included in any standard 
System documentation, a fully developed system may, in many 
cases, have to be transferred to another facility that may 
not have the same operation environment (equipment, operating 
SYSECM, etc. ).< 

In such cases, the agency that developed the system will have 
to provide additional information to facilitate the transfer. 
This information may include: 


Indication of human resources required to set up and run 
the system; 


Indication of software requirements such as size of central 
storage, type of computer, software and languages required; 


Indication of the time required to start the system; 
Probable installation costs; 

System operating costs; 

Required or probable modifications; 


System evaluation procedures. 
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COMMENT SHEET 


Your comments on any aspect of this document are 


Please send them to: 


Your Name: 
Address: 


Telephone Number: 


Mr. G. Gervais 

Senior Coordinator 
National Work Group 
TOT imerVOOt mI De CtLOn OO", 
R.H. Coats Building, 
Tunney's Pasture 

Ottawa, Ontario. 

K1A OT6 


(613) 995-0746 
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